Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wayland qt kde clipboard fix #863

Conversation

the-snowwhite
Copy link
Contributor

I now know the buzzwords are:

"Eclipse support for Wayland clipboard content types (RFC-1341 types)"

#851 (comment)

However the main motivation here is:

"Being able to use Eclipse comfortably with a LTS based linux distro in a wayland session in 2023"

The first commit already has an open pr #861 the second has been tested to work via this method #858
and then cherry picked from R_29_maintenance branch onto master without any issues.

@akurtakov
Copy link
Member

The change looks good to me and I confirm it fixes the issue.
For some reason verification build fails which prevents me from merging right now.

Copy link
Contributor

github-actions bot commented Nov 8, 2023

Test Results

     299 files  ±0       299 suites  ±0   6m 15s ⏱️ +24s
  4 095 tests ±0    4 087 ✔️ ±0    8 💤 ±0  0 ±0 
12 197 runs  ±0  12 124 ✔️ ±0  73 💤 ±0  0 ±0 

Results for commit 666b7fd. ± Comparison against base commit f139e4f.

♻️ This comment has been updated with latest results.

@mickaelistria mickaelistria force-pushed the wayland_qt_kde_clipboard_fix branch from 3c2143f to c50b990 Compare November 8, 2023 15:09
@the-snowwhite the-snowwhite force-pushed the wayland_qt_kde_clipboard_fix branch from c50b990 to 3fd6842 Compare November 8, 2023 15:16
@the-snowwhite
Copy link
Contributor Author

the-snowwhite commented Nov 8, 2023

@akurtakov
Seems like I had made a mishap when doing the interactive rebase in Eclipse So that
the first commit was there twice.
I have now squashed the 2 commits so that there only are the 2 commits now.
And force pushed again.

enables paste from KDE/QT apps to Eclipse in a wayland session.
…wayland clipboard

Enables copy from eclipse to KDE/QT apps in a wayland session(RFC-1341)
@iloveeclipse
Copy link
Member

Most likely due eclipse-tycho/tycho#2996

@the-snowwhite the-snowwhite force-pushed the wayland_qt_kde_clipboard_fix branch from 3fd6842 to 666b7fd Compare November 8, 2023 15:23
@the-snowwhite
Copy link
Contributor Author

OK
have just rebased and force pushed the branch again

@the-snowwhite
Copy link
Contributor Author

@akurtakov
I think this is the next workflow to approve including both the commit fixes and the rebase to master:
https://github.com/eclipse-platform/eclipse.platform.swt/actions/runs/6800349531

@mickaelistria mickaelistria merged commit c7549d9 into eclipse-platform:master Nov 8, 2023
5 of 7 checks passed
@mickaelistria
Copy link
Contributor

Build failure seems to happen everytime between reference to new native is committed, and an I-Build is available. Let's just merge anyway (which is relatively risky, but that's worth taking the risk as long as we've not fixed the build to prevent the error from happening on unrelated changes).

@mickaelistria
Copy link
Contributor

@the-snowwhite Thank you!

@the-snowwhite the-snowwhite deleted the wayland_qt_kde_clipboard_fix branch November 8, 2023 16:07
@iloveeclipse
Copy link
Member

Build failure seems to happen everytime between reference to new native is committed, and an I-Build is available. Let's just merge anyway (which is relatively risky, but that's worth taking the risk as long as we've not fixed the build to prevent the error from happening on unrelated changes).

Please don't merge things if they cannot be built. At least the root cause should have been identified and addressed somehow.

@mickaelistria
Copy link
Contributor

Please don't merge things if they cannot be built. At least the root cause should have been identified and addressed somehow.

Look at history and CI checks, you'll see it's unfortunately be the only productive workflow so far as no-one seems to be eager to fix it. I agree it's not good, but our failure to stabilize CI shouldn't be a reason for preventing locally tested patches from being merged if there is enough confidence in the patch.

@iloveeclipse
Copy link
Member

Look at history and CI checks, you'll see it's unfortunately be the only productive workflow so far

Not sure which history you mean. I'm not aware about broken builds in SWT.

as no-one seems to be eager to fix it

If no one reports a problem, it unlikely goes away.

@the-snowwhite
Copy link
Contributor Author

All I can find on this build issue is the log entity:

16:28:25  BUILD FAILED
16:28:25  /home/jenkins/agent/workspace/eclipse.platform.swt_PR-863/eclipse.platform.swt/bundles/org.eclipse.swt/buildSWT.xml:309: Unable to determine new tag

here:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-863/lastBuild/console

@mickaelistria
Has this issue been reported ?
Is there a bug tracker or any other sort of thread for this build issue ?

@the-snowwhite
Copy link
Contributor Author

The first build of this PR was a success:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-863/lastSuccessfulBuild/
But I don't understand why the console log is totally different ?

@the-snowwhite
Copy link
Contributor Author

the-snowwhite commented Nov 9, 2023

@iloveeclipse
From your Input I guess the solution would be to add:

output.. = bin/

to the build.properties file ?

eclipse-tycho/tycho#3019

@akurtakov
Should I try creating a PR for this in: --> https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/build.properties
Would it work to merge that PR if it builds successfully and then re-trigger #863 ?
and the use that as a test case for a mass edit of the concerned build.properties files ?

@iloveeclipse
Copy link
Member

I will have a look in an hour or two, here is the reason why one should never ignlre build fails:

eclipse-platform/eclipse.platform.releng.aggregator#1528

@akurtakov
Copy link
Member

akurtakov commented Nov 9, 2023

@the-snowwhite There is nothing related to this patch IMHO #867 (comment) . Of course, we will be really thankful if you look into the build failure which lies somewhere in the Ant build files of swt somewhere (95% sure I am) and would have happened without your patch..

@the-snowwhite
Copy link
Contributor Author

@akurtakov
Thank you for your kindness.
I have created an issue that hopefully can act as a placeholder to get builds working again:
#868

// This is a simplified example; actual encoding depends on RFC-1341 standards
// String rfc1341Text = "Content-Type: " + TEXTPLAINUTF8 + "\r\n\r\n" + text;
String rfc1341Text = text;
return rfc1341Text.getBytes(StandardCharsets.UTF_8);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see #875 (comment)

I have my doubts what this method does.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the method should be named convertToUTF8, as RFC 1341 is the standard that talks about the formatting if "MIME types" (i.e. the maintype/subtype;options format), and isn't actually about UTF strings. Also, the code of the method is pretty simple - effectively a short one liner - so maybe it can just be used directly in the one place it is being used.

@@ -169,6 +169,9 @@ boolean setData(Clipboard owner, Object[] data, Transfer[] dataTypes, int clipbo
System.arraycopy(entries, 0, tmp, 0, entries.length);
tmp[entries.length] = entry;
entries = tmp;
TransferData tdata = new TransferData();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is non-functional. Why it was added?

Copy link
Contributor Author

@the-snowwhite the-snowwhite Nov 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These 3 lines where needed to get Eclipse to present text/plain;uft-8 data to the clipboard.
Otherwise the javaToNative function in Texttreanfer.java was'nt called.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This I confirmed by the eclipse debugger

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong - have you asked why does the rest of clipboard data works but only new type would need that? I would assume you've missed something else.

The javaToNative is called from org.eclipse.swt.dnd.ClipboardProxy.getFunc(long, long, long, long)

iloveeclipse added a commit to iloveeclipse/eclipse.platform.swt that referenced this pull request Nov 10, 2023
1) The utf-8 content should be same as in UTF8_STRING, it just should
use different label/type id.
2) The change in ClipboardProxy.setData() was non functional and makes
no sense, it only leaks memory/wastes time

See eclipse-platform#863
See eclipse-platform#851
@iloveeclipse
Copy link
Member

The change here is not OK.
See #879

iloveeclipse added a commit that referenced this pull request Nov 10, 2023
1) The utf-8 content should be same as in UTF8_STRING, it just should
use different label/type id.
2) The change in ClipboardProxy.setData() was non functional and makes
no sense, it only leaks memory/wastes time

See #863
See #851
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants